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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETR 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of 
ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the ETSI 
Web server (http://www.etsi.fr/ipr). 

Pursuant to the ETSI Interim IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No 
guarantee can be given as to the existence of other IPRs not referenced in ETR 314 (or the updates on 
http://www.etsi.fr/ipr) which are, or may be, or may become, essential to the present document. 



Foreword 



This ETSI Technical Specification (TS) has been produced by the Special Mobile Group (SMG) of the European 
Telecommunications Standards Institute (ETSI). 

This specification specifies the Customized Applications for Mobile network Enhanced Logic (CAMEL) CAMEL 
Application Part (CAP) within the digital cellular telecommunications system (Phase 2/Phase 2+). 

The contents of this TS are subject to continuing work within SMG and may change following formal SMG approval. 
Should SMG modify the contents of this TS, it will then be republished by ETSI with an identifying change of release 
date and an increase in version number as follows: 

Version S.x.y 

where: 

y the third digit is incremented when editorial only changes have been incorporated in the specification; 

X the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc. 

The following subclauses have been modified in this version: 6.3, 8.1.10.4, 9.25.1 and 9.25.3.1. Annex B has been 
deleted. 
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1 Scope 



This standard specifies the CAMEL Application Part (CAP) supporting the first phase of the network feature 
Customized AppUcations for Mobile network Enhanced Logic. CAP is based on a sub-set of the CS 1 Core INAP as 
specified by ETS 300 374-1 [14]. Descriptions and definitions provided by ETS 300 374-1 [14] are directly referenced 
by this standard in case no additions or clarifications are needed for the use in the CAP. 



Normative references 



References may be made to: 

a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in 
which case, subsequent revisions to the referenced document do not apply; or 

b) all versions up to and including the identified version (identified by "up to and including" before the version 
identity); or 

c) all versions subsequent to and including the identified version (identified by "onwards" following the version 
identity); or 

d) publications without mention of a specific version, in which case the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[I] ETS 300 008 (1993): "Integrated Services Digital Network (ISDN); CCITT SignalHng System 
No.7; Message Transfer Part (MTP) to support international interconnection". 

[2] ETS 300 009 (1994): "Integrated Services Digital Network (ISDN); CCITT SignalHng System 

No.7; Signalling Connection Control Part (SCCP) [connectionless and connection-oriented] to 
support international interconnection". 

[3] ETS 300 287 (1993): "Integrated Services Digital Network (ISDN); CCITT Signalling System 

No.7; Transaction Capabilities Application Part (TCAP) version 2". 

[4] ETS 300 356-1: "Integrated Services Digital Network (ISDN); CCITT Signalling System No.7; 

ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services". 

[5] ETS 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber SignalHng 

System No. one (DSSl); User-network interface layer 3 specification for basic call control; Part 1: 
Protocol specification [ITU-T Recommendation Q.931 (1993), modified]". 

[6] ITU-T Recommendation Q.773 (1993): "Specifications of Signalling System No.7; Transaction 

Capabilities formats and encoding". 

[7] ITU-T Recommendation Q.1218 (19935): "Interface Recommendation for intelligent network 

CSl". 

[8] ITU-T Recommendation Q. 1400 (1993): "Architecture framework for the development of 

signalling and organization, administration and maintenance protocols using OSI principles". 

[9] CCITT Recommendation X.208 (1988): "Specification of Abstract Syntax Notation One 

(ASN.l)". 

[10] CCITT Recommendation X.209 (1988): "Specification of basic encoding rules for Abstract Syntax 

Notation One (ASN.l)". 

[I I] CCITT Recommendation X.219 (1988): "Remote operations: Model, notation and service 
definition". 

[12] CCITT Recommendation X.229 (1988): "Remote operations: Protocol specification". 
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[13] ISO 9545 (1989): "Information technology - Open Systems Interconnection - Application Layer 

structure". 

[14] ETS 300 374-1 (1994): "Intelligent Network (IN); Intelligent Network Capability Set 1 (CSl) Core 

Intelligent Network Application Protocol (INAP) Part 1: Protocol specification". 

[15] GSM 09.02 (ETS 300 974): "Digital cellular telecommunications system (Phase 2+); Mobile 

Application Part (MAP) specification". 

[16] GSM 03.78 (TS 101 044): "Digital cellular telecommunications system (Phase 2+); Customised 

Applications for Mobile network Enhanced Logic (CAMEL) - stage 2". 

[17] CCITT Recommendation Q.713 : "Specifications of Signalling System No. 7; SCCP formats and 

codes". 

[18] ITU-T Recommendation X.680 (1994) I ISO/IEC 8824-1:1994, Information technology - Open 

Systems Interconnection - Abstract Syntax Notation One (ASN.l): Specification of basic notation. 

[19] ITU-T Recommendation X.681 (1994) I ISO/lEC 8824-2:1994, Information technology - Open 

Systems Interconnection - Abstract Syntax Notation One (ASN.l): Information object 
specification. 

[20] ITU-T Recommendation X.682 (1994) I ISO/IEC 8824-3:1994, Information technology - Open 

Systems Interconnection - Abstract Syntax Notation One (ASN.l): Constraint specification. 

[21] ITU-T Recommendation X.683 (1994) I ISO/IEC 8824-4:1994, Information technology - Open 

Systems Interconnection - Abstract Syntax Notation One (ASN.l): Parameterization of ASN.l 
specifications. 

[22] ITU-T Recommendation X.690 (1994) I ISO/IEC 8825-1:1994, Information technology - Open 

Systems Interconnection - Specification of ASN.l encoding rules: Basic, Canonical, and 
Distinguished Encoding Rules. 

[23] ITU-T Recommendation X.880 (1994) I ISO/IEC 13712-1:1994, Information technology - Remote 

Operations: Concepts, model and notation. 

[24] GSM 09. 12 (prETS 300 646-1): "Digital cellular telecommunications system (Phase 2); SignalHng 

System No 7 - Application of ISUP version 2 for the ISDN-PLMN (GSM) signalling Interface 

[25] GSM 04.08 (ETS 300 940): "Digital cellular telecommunications system (Phase 2+); Mobile radio 

interface layer 3 specification". 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AC Application Context 

ACM Address Complete Message 

AE Application Entity 

ASE Application Service Element 

ASN. 1 Abstract Syntax Notation One 

BCSM Basic Call State Model 

CAP CAMEL Application Part 

CSl Capability Set 1 

CSI CAMEL Subscription Information 

DP Detection Point 

DSSl Digital Subscriber Signalling System No. One 

EDP Event Detection Point 

EDP-R Event Detection Point - Request 

FE Functional Entity 

FSM Finite State Model 

gsmSCF GSM SCF 
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gsmSSF GSM SSF 

lAM Initial Address Message 

ID Identifier 

IN Intelligent Network 

INAP Intelligent Network Application Protocol 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part 

MACF Multiple Association Control Function 

MTP Message Transfer Part 

OCSI Originating CSI 

PE Physical Entity 

REL Release 

ROSE Remote Operations Service Element 

SACF Single Association Control Function 

SAO Single Association Object 

SCCP Signalling Connection Control Part 

SCF Service Control Function 

SCME SCF Management Entity 

SCSM SCF Call State Model 

SLP Service Logic Program 

SSF Service Switching Function 

SSME SSF Management Entity 

SSN Sub-System Number 

TC Transaction Capabilities 

TCAP Transaction Capabilities Application Part 

TCSI Terminating CSI 

TDP Trigger Detection Point 

TDP-R Trigger Detection Point - Request 



4 General 

4.1 Definition methodology 

The definition of the protocol is split into three Clauses: 

the definition of the Single/Multiple Association Control Function (SACF/MACF) rules for the protocol 

(Clause 5); 

the definition of the operations transferred between entities (Clause 6); 

the definition of the actions taken at each entity (Clause 7). 

The SACF/MACF rules are defined in prose. The operation definitions are in Abstract Syntax Notation 1 (ASN.l, see 
CCITT Recommendation X.208 [9]), and the actions are defined in terms of state transition diagrams. Further guidance 
on the actions to be performed on receipt of an operation can be gained from Clause 6 and from the relevant detailed 
procedures in Clause 7. 

The CAP is a Remote Operations Service Element (ROSE) user protocol (see CCITT Recommendations X.219 [11] and 
X.229 [12] and ITU-T Recommendation X.880 [23]). CAP uses the Basic Encoding Rules (see CCITT 
Recommendation X.209 [10] and ITU-T recommendation X.690 [22]). 



4.2 



Spare 



4.3 CAP protocol architecture 



Many of the terms used in this subclause are based on the OSI Application Layer Structure as defined in ISO 9545 [13]. 
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The CAP protocol architecture can be illustrated as shown in figure 1 . 
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Interactions (case b) 
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Figure 1 : CAP protocol architecture 

A PE has either single interactions (case a) or multiple co-ordinated interactions (case b) with other PEs. 

In case a, SACF provides a co-ordination function in using Application Service Elements (ASEs), which includes the 
ordering of operations supported by ASE(s), (based on the order of received primitives). The Single Association Object 
(SAO) represents the SACF plus a set of ASEs to be used over a single interaction between a pair of PEs. 

In case b, MACF provides a co-ordinating function among several S AOs, each of which interacts with an SAO in a 
remote PE. 

Each ASE supports one or more operations. Description of each operation is tied with the action of corresponding FE 
modelling (see GSM 03.78 [16] and Clause 7 of this ETS). Each operation is specified using the operation macro 
described in figure 2. 
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INAPUserASE's 



xyz OPERATION 

ARGUMENT {Parameterl , Parameter2,...} 
RESULT {Parameterl , Parameter2,...} 
LINKED {operations, operation4,...} 
ERRORS {errorl , error2....} 

errorl ERROR 

PARAMETER {Parameters, Parameter?,...} 
etc 



to peer 



Operations 

Results 

Errors 



TCAP ASE 



COMPONENT SUB-LAYER 



to peer 



TRANSACTION SUB-LAYER 



to peer 



: 



INVOKE 

RETURN RESULT 
RETURN ERROR 
REJECT 

BEGIN 

CONTINUE 

END 

ABORT 

UNIDIRECTIONAL 



CONNECTIONLESS SCCP 

Figure 2: Operation description 

The use of the Application Context (AC) negotiation mechanism (as defined in ETS 300 287 [3]) allows the two 
communicating entities to identify exactly what their capabilities are and also what the capabilities required on the 
interface should be. This should be used to allow evolution through capability sets. 

If the indication of a specific AC is not supported by a pair of communicating FEs, some mechanism to pre-arrange the 
context shall be supported. 



4.4 CAP addressing 

The CAMEL Application Part makes use of the services offered by the Signalling Connection Control Part of signalling 
System No. 7. CCITT Blue Book or ITU-T (03/93) Recommendations Q.71 1 to Q.716 should be consulted for the full 
specification of SCCP. 

4.4.1 Sub-System Number (SSN) 

The use of SSN is a network operator option and values for intra-PLMN usage are network specific. 

4.4.2 Quality of service parameters 

The class (class or class 1) of SCCP is set as required by the application. However class 1 shall be requested by any 
application that can send more than 1 TCAP message to its peer (iconsecutive TR-CONTINUE) before receiving a 
response from its peer (TR-CONTINUE or TR-END). RESULT_NL should not be used. However, if RESULT_NL is 
used by the application (and thus segmentation is needed) class 1 shall be set by the application. 

According to Q.771, TC imposes no limitation on the number of segments. However if the peer TC users are certain that 
the Network Service used supports segmentation and reassembly of user data, the TC_RESULT_NL (RR_NL) facility is 
not necessary and should be avoided. 



The return option may be used if requested by the application (Network Operator to determine). 
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4.4.3 SCCP addressing 

Within the GSM System there is a need to communicate between entities within the same PLMN and in different 
PLMNs. Using the CAMEL AppHcation Part (CAP) for this function impHes the use of Transaction Capabilities (TC) 
and the SignalHng Connection Control Part (SCCP) of CCITT SignalHng System No. 7. 

The format and coding of address parameters carried by the SCCP for that purpose shall comply with CCITT 
Recommendation Q.713 [17] with the following restrictions: 

1) Intra-PLMN addressing 

For communication between entities within the same PLMN, the use of SCCP addressing is network specific. 

2) Inter-PLMN addressing 

a) Called Party Address 

SSN indicator = a standardised SSN shall be used. The code point will be allocated by the appropriate 
ETSI body; 

Point Code indicator = 0; 

Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and 
nature of address indicator); 

Translation type = (Not used); 

Routing indicator = (Routing on global title); 

b) Calling Party Address 

- SSN indicator = a standardised SSN shall be used. The code point will be allocated by the appropriate 
ETSI body; 

Point code indicator = 0; 

- Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and 
nature of address indicator); 

Translation type = (Not used); 

- Routing indicator = (Routing on Global Title). 

4.5 Spare 

4.6 Compatibility mechanisms used for CAP 
4.6.1 Introduction 

This subclause specifies the compatibility mechanisms that shall be used for CAP 

Two major categories of compatibility are handled by these mechanisms: 

compatibility with the ITU-T Recommendation Q. 1218 [7] version of CS 1 INAP and the ETSI specification 
ETS 300 374 -1 version [14] of CSl INAP; 

compatibility with future versions of CAP. 

The second category has three sub-categories of compatibility dealt with in this subclause: 

minor changes to the CAP in future standardized versions: 

A minor change can be defined as a change of a functionality which is not essential for the requested CAMEL 
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service. In case it is a modification of an existing function, it is acceptable that the addressed function is executed 
in either the older or the modified variant. If the change is purely additional, it is acceptable that it is not executed 
at all and that the peer Application Entity (AE) need not know about the effects of the change. For minor 
changes, a new AC is not required; 

major changes to the CAP in future standardized versions: 

A major change can be defined as a change of a functionality which is essential for the requested CAP service. In 
case it is a modification of an existing function, both application entities shall have a shared knowledge about the 
addressed functional variant. If the change is purely additional, the requested CAMEL service will not be 
provided if one of the application entities does not support the additional functionality. For major changes, a new 
AC is required; 

network specific changes to CAP: 

These additions may be of either the major or minor type for a service. No new AC is expected to be defined for 
this type of change. At the time of definition, the additions would not be expected to be included in identical form 
in future versions of the ETS. 

4.6.2 Definition of CAP compatibility meciianisms 

4.6.2.1 Compatibility mechanism for interworking of CAP with ETSI CS1 Core INAP 
and ITU-T Q.1 21 8 INAP 

On receipt of an operation according to ITU-T Recommendation Q.1218 [7] or an operation according to ETSI 

ETS 300 374-1 [14] which is not part of the CAP or is part of the CAP but which contains parameters which are not part 

of the CAP: 

the gsmSSF shall apply the normal error handling for unknown operations or parameters, i.e. the normal error 
handling procedures as specified in Clause 10 shall be followed; 

the gsmSCF shall apply the normal error handling for unknown operations or parameters except for parameters in 
the InitialDP operation. All parameters specified in ITU-T Recommendation Q.1218 [7] and in ETSI 
ETS 300 374-1 [14] for InitialDP shall be known by the gsmSCF, those not included in the CAP shall be 
ignored. 

Tagging of CAP additions to ITU-T Recommendation Q.1218[7] and ETSI ETS 300 374-1 [14] are specified from 50 
and upwards. 

4.6.2.2 Procedures for major additions to CAP 

In order to support the introduction of major functional changes, the protocol allows a synchronization between the two 
applications with regard to which functionality is to be performed. This synchronization takes place before the new 
function is invoked in either application entity, in order to avoid complicated fall-back procedures. The solution chosen 
to achieve such a synchronization is use of the AC negotiation provided in ETS 300 287 [3]. 

4.6.2.3 Procedures for minor additions to CAP 

The extension mechanism marker shall be used for future standardized minor additions to CAP. This mechanism 
implements extensions by including an "extensions marker" in the type definition. The extensions are expressed by 
optional fields that are placed after the marker. When an entity receives unrecognized parameters that occur after the 
marker, they are ignored (see ITU-T Recommendation X.680 [18]). 

4.6.2.4 Procedures for inclusion of network specific additions to CAP 

This mechanism is based on the ability to explicitly declare fields of any type via the Macro facility in ASN.l at the 
outermost level of a type definition. It works by defining an "ExtensionField" that is placed at the end of the type 
definition. This extension field is defined as a set of extensions, where an extension can contain any type. Each 
extension is associated with an identification that unambiguously identifies the extension. Refer to ITU-T 
Recommendation Q. 1400 [8] for a definition of this mechanism. 



GSM 09.78 version 5.3.0 15 TS 1 01 046 V5.3.0 (1 998-01 ) 

5 Single/Multiple Association Control Function 

(SACF/MACF) rules 

5.1 Reflection of TCAP Application Context (AC) 

TCAP AC negotiation rules require that the proposed AC, if acceptable, is reflected in the first backwards message. 

If the AC is not acceptable, and the TC-User does not wish to continue the dialogue, it may provide an alternate AC to 
the initiator which can be used to start a new dialogue. 

TCAP AC negotiation applies only to the gsmSCF interfaces. Refer to ETS 300 287 [3] for a more detailed description 
of the TCAP AC negotiation mechanism. 

5.2 Sequential/parallel execution of operations 

In some cases, it may be necessary to distinguish whether operations should be performed sequentially or in parallel 
(synchronized). Operations which may be synchronized are: 

charging operations may be synchronized with any other operation. 

The method of indicating that operations are to be synchronized is to include them in the same message. Where it is 
impossible to execute one of the operations identified above until some other operation has progressed to some extent or 
finished, the sending PE (usually SCP) can control this by sending the operations in two separate messages. 

This method does not imply that all operations sent in the same message should be executed simultaneously, but simply 
that where it could make sense to do so (in the situations identified above) the operations should be synchronized. 

In case of inconsistency between the above mentioned generic rules and the FE-specific rules as specified in Clause 7, 
the FE-specific rules take precedence over the generic rules. 



Abstract syntax of the CAP 



This Clause specifies the abstract syntax for the CAP version 1, using ASN.l as defined in CCITT Recommendation 
X.208 [9] and ITU-T Recommendations X.680 [18], X.681 [19], X.682 [20] and X.683 [21]. 

The encoding rules which are applicable to the defined abstract syntax are the Basic Encoding Rules for ASN.l, defined 
in CCITT Recommendation X.209 [10] and ITU-T Recommendation X.690 [22] with the restrictions as described in 
ITU-T Recommendation Q.773 [6], § 4.1.1, modified by ETS 300 287 [3]. Additional encodings are cited for 
parameters used in existing ISUP (ETS 300 356-1 [4]) and DSSl (ETS 300 403-1 [5]) standards. 

For the ISUP and DSS 1 parameters used in the CAP, only the coding of the parameter value is coded as defined in ISUP 
or DSSl. The DSSl/ISUP defined parameter identifiers are removed and replaced by the CAP defined parameter 
identifiers. 

Where possible existing data types from the CSl ETSI Core INAP (ETS 300 374-1 [14]) and MAP (Where possible 
existing data types from the CSl ETSI Core INAP (ETS 300 374-1 [14]) and MAP (ETS 300 974 [15]) standards have 
been used. 

The mapping of OPERATION and ERROR to TCAP components is defined in ITU-T Recommendation Q.773 [6] 
modified by ETS 300 287 [3]. The class of an operation is not stated explicitly but is specified in the ASN.l 
OPERATION MACRO, as follows: 

class 2: only ERRORS appears in the ASN. 1 OPERATION MACRO definition; 

class 3: only RESULT appears in the ASN. 1 OPERATION MACRO definition; 

class 4: neither RESULT nor ERRORS appears in the ASN. 1 OPERATION MACRO definition. 
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The abstract syntax for CAP is composed of several ASN.l modules describing operations, errors, and associated data 
types. The values (operation codes and error codes) are defined in a separate module. 

The module containing all the type definitions for CAP operations is CAP-Operations and is described in 
subclause 6.1. 

The module containing all the type definitions for CAP errors is CAP-Errors and is described in subclause 6.2. 

The module containing all the type definitions for CAP data types is CAP-DataTypes and is described in subclause 6.3. 

The module containing the operation codes and error codes for CAP is CAP-Codes and is described in subclause 6.4. 

All the AC definitions for CAP are described in subclause 6.5. 

The module containing the class definitions for CAP is CAP-Classes and is described in subclause 6.6. 



6.1 Operation types 



CAP-Operations (ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) gsm-Network (1) 

modules (3) 

cap-operations (50) versionl(O)} 

— This module contains the type definitions for the CAP v.l operations. 
DEFINITIONS : := 

BEGIN 

IMPORTS 

OPERATION 

FROM TCAPMessages (ccitt recommendation q 773 modules (2) messages (1) version2(2)} 

error types 

MissingCustomerRecord, 

MissingParameter, 

TaskRefused, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 

FROM Core-INAP-CSl-Errors (ccitt (0) identif ied-organization (4 ) etsi(O) inDomain(l) in-network ( 1 ) 
modules (0) csl-errors (1) versionl(O)} 

— CAP error types 
SystemFailure 

FROM CAP-Errors (ccitt (0) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) gsm-Network ( 1 ) 
modules (3) cap-errors (51) versionl(O)} 

argument types 

ConnectArg, 

Event Report BCSMArg, 

InitialDPArg, 

ReleaseCallArg, 

RequestReportBCSMEventArg 

FROM CAP-DataTypes (ccitt (0) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) gsm-Network ( 1 ) 
modules (3) cap-datatypes (52) versionl (0) } ; 

— TYPE DEFINITIONS FOR CAP v.l OPERATIONS FOLLOW 

ActivityTest ::= OPERATION 

RESULT 

Direction: gsmSCF -> gsmSSF, Timer: T^^ 

— This operation is used to check for the continued existence of a relationship between the 

— gsmSCF and gsmSSF. If the relationship is still in existence, then the gsmSSF will respond. 

— If no reply is received, then the gsmSCF will assume that the gsmSSF has failed in some way 

— and will take the appropriate action. 

Connect ::= OPERATION 

ARGUMENT 

ConnectArg 
ERRORS ( 

MissingParameter, 
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SystemFailure, 

TaskRefused, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 

} 

— Direction: gsmSCF -> gsmSSF, Timer: T^^^ 

— This operation is used to request the gsmSSF to perform the call processing actions to route 

— or forward a call to a specified destination. To do so, the gsmSSF may or may not use 

— destination information from the calling party (e.g., dialled digits) and existing call setup 
information depending on the information provided by the gsmSCF. 

Continue ::= OPERATION 

— Direction: gsmSCF -> gsmSSF, Timer: T^^g 

This operation is used to request the gsmSSF to proceed with call processing at the DP at 

— which it previously suspended call processing to await gsmSCF instructions (i.e., proceed to 

— the next point in call in the BCSM) . The gsmSSF continues call processing without 

— substituting new data from gsmSCF. 

EventReportBCSM ::= OPERATION 

ARGUMENT 

EventReportBCSMArg 

— Direction: gsmSSF -> gsmSCF, Timer: T^^j^ 

— This operation is used to notify the gsmSCF of a call-related event (e.g., BCSM events such 

— as answer or disconnect) previously requested by the gsmSCF in a RequestReportBCSMEvent 
operation. 

InitialDP ::= OPERATION 

ARGUMENT 

InitialDPArg 
ERRORS { 

MissingCustomerRecord, 

MissingParameter, 

SystemFailure, 

TaskRefused, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 

} 

Direction: gsmSSF -> gsmSCF, Timer: T^^^^ 

— This operation is used after a TDP to indicate request for service. 

ReleaseCall ::= OPERATION 

ARGUMENT 

ReleaseCallArg 

Direction: gsmSCF -> gsmSSF, Timer: T^ 

— This operation is used to tear down an existing call at any phase of the call for all 

— parties involved in the call. 

RequestReportBCSMEvent ::= OPERATION 

ARGUMENT 

RequestReportBCSMEventArg 
ERRORS { 

MissingParameter, 

SystemFailure, 

TaskRefused, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 

} 

— Direction: gsmSCF -> gsmSSF, Timer: T^^j^ 

— This operation is used to request the gsmSSF to monitor for a call-related event (e.g., BCSM 

— events such as answer or disconnect), then send a notification back to the gsmSCF when the 
event is detected. 

END 

Operation timers 

The following value ranges apply for operation specific timers in CAP: 

short: 1 to 20 seconds; 

Table 1 lists all operation timers and the value range for each timer. The definitive value for each operation timer may 
be network specific and has to be defined by the network operator. 
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Table 1 



Operation Name 


Timer 


value 


ActivityTest 


Tat 


short 


Connect 


"•"con 


short 


Continue 


"•"cue 


short 


EventReportBCSM 


Terb 


short 


InitialDP 


Tjdp 


short 


ReleaseCall 


Trc 


short 


RequestReportBCSMEvent 


Trrb 


short 



6.2 Error types 



CAP-Errors ( ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) gsm-Network ( 1 ) modules (3) 
cap-errors (51) versionl (0) } 

— This module contains the type definitions for the CAP v.l errors. 
DEFINITIONS IMPLICIT TAGS ::= 

BEGIN 
IMPORTS 

ERROR 
FROM TCAPMessages (ccitt recommendation q 773 modules (2) messages (1) version2(2)} 

UnavailableNet wo rkRe source 

FROM CAP-DataTypes (ccitt (0) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) gsm-Network ( 1 ) 
modules (3) cap-datatypes (52) versionl (0) } ; 

— TYPE DEFINITIONS FOR CAP v.l ERRORS FOLLOW 

SystemFailure ::= ERROR 

PARAMETER 

UnavailableNet wo rkRe source 

— The operation could not be completed due to a system failure at the serving entity. 



6.3 Data types 



CAP-DataTypes (ccitt (0) identif ied-organization (4) etsi(O) mobileDomain (0) gsm-Network (1) modules (3) 
cap-datatypes (52) versionl (0)} 

— This module contains the type definitions for the CAP v.l data types. 

DEFINITIONS IMPLICIT TAGS ::= 

BEGIN 

IMPORTS 



CallingPartysCategory, 

HighLayerCompatibility, 

MiscCalllnfo, 

MonitorMode, 

Redirect ion Information, 

ServiceKey 

FROM Core-INAP-CSl-DataTypes ( ccitt (0) identif ied-organization (4 ) etsi(O) inDomain(l) 
in-network ( 1 ) modules (0) csl-datatypes (2 ) versionl (0)} 

IMS I, 
Ext-BasicServiceCode 

FROM MAP-CommonDataTypes ( ccitt (0) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) 
gsm-Network ( 1 ) modules (3) map-CommonDataTypes (18) version3(3)} 
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Location Information, 
Subscriber St ate 

FROM MAP-MS-DataTypes { ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) 
gsm-Network ( 1 ) modules (3) map-MS-DataTypes (11) versions (3)} 

CallRef erenceNumber, 
SuppressionOf Announcement 

FROM MAP-CH-DataTypes { ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) 
gsm-Network (1) modules (3) map-CH-DataTypes ( 13 ) version3(3)} 

ISDN-Address St ring, 

FROM MAP-CommonDataTypes { ccitt identif ied-organization (4 ) etsi(O) mobileDomain (0 ) 
gsm-Network (1) modules (3) map-CommonDataTypes (18) version3 (3)}; 



TYPE DEFINITIONS FOR CAP v.l DATA TYPES FOLLOW 



— Argument Data Types 



ConnectArg 

destinationRoutingAddress 

originalCalledPartylD 

extensions 

genericNumbers 
callingPartys Category 
redirectingPartylD 
redirectionlnformation 
SuppressionOf Announcement 
oCSIApplicable 



: := SEQUENCE { 

[0] DestinationRoutingAddress, 

[6] OriginalCalledPartylD OPTIONAL, 

[10] SEQUENCE SIZE ( 1 .. numOf Extensions ) OF ExtensionField 

OPTIONAL, 
[14] GenericNumbers OPTIONAL, 

[28] CallingPartysCategory OPTIONAL, 
[29] RedirectingPartylD OPTIONAL, 
[30] Redirectionlnformation OPTIONAL, 
[55] SuppressionOfAnnouncement OPTIONAL, 
[56] OCSIApplicable OPTIONAL, 



EventReportBCSMArg ::= 

event TypeBCSM [0] 

eventSpecif IcInformationBCSM [2] 

leglD [3] 

miscCalllnfo [4] 

extensions [5] 



SEQUENCE { 
EventTypeBCSM, 

Event Specific InformationBCSM OPTIONAL, 
LegID OPTIONAL, 

MiscCalllnfo DEFAULT (messageType request} 

SEQUENCE SIZE (1. .numOfExtensions) OF ExtensionField 

OPTIONAL, 



InitialDPArg : := 

serviceKey [0] 

calledPartyNumber [2] 

callingPartyNumber [3] 

CallingPartysCategory [5] 

locationNumber [10 

originalCalledPartylD [12 

extensions [15 

highLayerCompatibility [23 
additionalCallingPartyNumber [25 

bearerCapability [27 

eventTypeBCSM [28 

redirectingPartylD [29 

redirectionlnformation [30 

iMSI [50 

subscriberState [51 

locationinf ormation [52 

ext-basicServiceCode [53 

callReferenceNumber [54 

mscAddress [55 

calledPartyBCDNumber [56 



SEQUENCE { 

ServiceKey, 

CalledPartyNumber 

CallingPartyNumber 

CallingPartysCategory 

LocationNumber 

OriginalCalledPartylD 

SEQUENCE SIZE (1. .numOfExte 

OPT 

HighLayerCompatibility 

AdditionalCallingPartyNumb' 

BearerCapability 

EventTypeBCSM 

RedirectingPartylD 

Redirectionlnformation 

IMSI 

SubscriberState 

Locationinf ormation 

Ext-BasicServiceCode 

CallReferenceNumber 

ISDN-Address St ring 

CalledPartyBCDNumber 



OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 
nsions) OF ExtensionField 
lONAL, 

OPTIONAL, 
er OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL 



ReleaseCallArg 



Cause 



RequestReportBCSMEventArg 
bcsmEvents 
extensions 



: := SEQUENCE { 

[0] SEQUENCE SIZE ( 1 . . numOf BCSMEvent s ) OF BCSMEvent, 
[2] SEQUENCE SIZE ( 1 .. numOfExtensions ) OF ExtensionField 

OPTIONAL, 



Indicates the BCSM related events for notification. 
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— Common Data Types 

AdditionalCallingPartyNumber ::= Digits 

— Indicates the Additional Calling Party Number. 

BCSMEvent ::= SEQUENCE { 

eventTypeBCSM [0] EventTypeBCSM, 

monitorMode [1] MonitorMode, 

leglD [2] LegID OPTIONAL 

} 

— Indicates the BCSM Event information for monitoring. 

BearerCapability ::= CHOICE { 

bearerCap [0] OCTET STRING (SIZE (2 . .maxBearerCapabilityLength) ) 

} 

Indicates the type of bearer capability connection to the user. For bearerCap, the value as 

— described in ISUP (ETS 300 356-1 [4], User Service Information) shall be used. 

CalledPartyBCDNumber ::= OCTET STRING (SIZE (minCalledPartyBCDNumberLength .. 

maxCalledP art yBCDNumber Length) 

— Indicates the Called Party Number, including service selection information. Refer to GSM 

— 04.08 [25] for encoding. This data type carries only the "type of number", "numbering plan 

— identification" and "number digit" fields defined in [25]; it does not carry the "called 

— party BCD number lEI" or "length of called party BCD number contents". 

CalledPartyNumber ::= OCTET STRING (SIZE (minCalledPartyNumberLength .. 

maxCalledPartyNumberLength) ) 

Indicates the Called Party Number. Refer to ETS 300 356-1 [4] for encoding. 

CallingPartyNumber ::= OCTET STRING (SIZE (minCallingPartyNumberLength .. 

maxCallingPartyNumberLength) ) 

Indicates the Calling Party Number. Refer to ETS 300 356-1 [4] for encoding. 

Cause ::= OCTET STRING (SIZE (minCauseLength .. maxCauseLength) ) 

Indicates the cause for interface related information. Refer to the ETS 300 356-1 [4] Cause 

— parameter for encoding. For the use of Cause and Location values refer to Q.850. 

— Shall only include the cause value. 

DestinationRoutingAddress ::= SEQUENCE SIZE (1) OF CalledPartyNumber 

— Indicates the Called Party Number. 

Digits ::= OCTET STRING (SIZE (minDigitsLength .. maxDigitsLength) ) 

— Indicates the address signalling digits. Refer to the ETS 300 356-1 [4] Generic Number and 

— Generic Digits parameters for encoding. The coding of the subfields "NumberQualif ier" in 
Generic Number and "Type Of Digits" in Generic Digits are irrelevant to the CAP, the ASN.l 

— tags are sufficient to identify the parameter. The ISUP format does not allow to exclude 

— these subfields, therefor the value is networlc operator specific. 

— The following parameter should use Generic Number; 

— AdditionalCallingPartyNumber for InitialDP 

EventSpecificInformationBCSM ::= CHOICE { 

oDisconnectSpecificInfo [7] SEQUENCE { 

releaseCause [0] Cause OPTIONAL 

}, 
tDisconnectSpecificInfo [12] SEQUENCE { 

releaseCause [0] Cause OPTIONAL 



Indicates the call related information specific to the event. 

EventTypeBCSM ::= ENUMERATED { 

collectedlnfo (2) , 
oAnswer (7) , 
oDisconnect (9) , 
termAttemptAuthorized ( 12 ) , 
tAnswer (15) , 
tDisconnect (17) 



GSM 09.78 version 5.3.0 



21 



TS101 046 V5.3.0 (1998-01) 



Values collectedlnfo and termAttemptAuthorized can only be 
used for TDPs. 



ExtensionField ::= SEQUENCE { 

type EXTENSION. Sid ( { SupportedExtensions } ) , 

— shall identify the value of an EXTENSION type 
criticality 

EXTENSION. scriticality ( {SupportedExtensions} {@type} ) , 
value [1] EXTENSION. SExtensionType 

( { SupportedExtensions } { @type} ) 
} 
— This parameter indicates an extension of an argument data type. Its content is network operator 
specific 



GenericNumber 



::= OCTET STRING (SIZE (minCenericNumberLength . . 
maxGenericNumberLength) ) 



Indicates a generic number. Refer to ETS 300 356-1 [4] Generic number for encoding. 

GenericNumbers ::= SET SIZE ( 1 . . numOf GenericNumbers ) OF GenericNumber 

LegID : := CHOICE { 

sendingSidelD [0] LegType, — used in operations sent from gsmSCF to gsmSSF 
receivingSidelD [1] LegType — used in operations sent from gsmSSF to gsmSCF 
} 

— Indicates a reference to a specific party in a call. 



LegType 

legl LegType 
leg2 LegType 

LocationNumber 



::= OCTET STRING (SIZE(l) 

'Ol'H 

'02'H 



OCTET STRING (SIZE (minLocat ionNumberLength 
maxLocationNumberLength) ) 



Indicates the Location Number for the calling party. Refer to ETS 300 356-1 [4] for encoding. 



OriginalCalledPartylD 



::= OCTET STRING (SIZE (minOriginalCalledPartylDLength .. 
maxOriginalCalledPartylDLength) ) 



— Indicates the original called number. Refer to ETS 300 356-1 [4] Original Called Number for 
encoding . 

OCSIApplicable ::= NULL 

— Indicates that the Originating CAMEL Subscription Information, if present, shall be applied on 
the 

— outgoing call leg created with a Connect operation. For the use of this parameter see GSM 
03.78 [16] . 



RedirectingPartylD 



::= OCTET STRING (SIZE (minRedirectingPartylDLength .. 
maxRedirectingPartylDLength) ) 



— Indicates redirecting number. Refer to ETS 300 356-1 [4] Redirecting number for encoding. 

UnavailableNetworkResource ::= ENUMERATED { 
unavailableResources (0) , 
componentFailure (1) , 
basicCallProcessingException (2) 



— Definition of range constants 

maxBearer Capability Length 

minCalledPartyBCDNumber Length 

maxCalledPartyBCDNumber Length 

minCalledPartyNumber Length 

maxCalledPartyNumber Length 

minCallingPartyNumber Length 

maxCallingPartyNumber Length 

minCauseLength 

maxCauseLength 

minDigitsLength 

maxDigitsLength 

minCenericNumberLength 

maxGenericNumberLength 

minLocat ionNumberLength 

maxLocationNumberLength 

minOriginalCalledPartylDLength 

maxOriginalCalledPartylDLength 

minRedirectingPartylDLength 



INTEGER : 


= 


11 


INTEGER : 


= 


1 


INTEGER : 


= 


41 


INTEGER : 


= 


3 


INTEGER : 


= 


12 


INTEGER : 


= 


2 


INTEGER : 


= 


10 


INTEGER : 


= 


2 


INTEGER : 


= 


2 


INTEGER : 


= 


3 


INTEGER : 


= 


11 


INTEGER : 


= 


3 


INTEGER : 


= 


11 


INTEGER : 


= 


2 


INTEGER : 


= 


10 


INTEGER : 


= 


2 


INTEGER : 


= 


10 


INTEGER : 


= 


2 
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maxRedirectingPartylDLength 
numOfBCSMEvents 
numOf Ext ens ions 
numOfGenericNumbers 

END 



INTEGER : 


= 10 


INTEGER : 


= 10 


INTEGER : 


= 10 


INTEGER : 


= 5 



6.4 Operation and error codes) 



CAP-Codes (ccitt(O) identif ied-organization (4) etsi(O) mobileDomain (0) gsm-Network (1) modules (3) 
cap-codes (53) versionl(O)} 

— This module contains the operation and error code assignments for the CAP v.l application 
protocol. 

DEFINITIONS : := 

BEGIN 

— OPERATION AND ERROR CODE ASSIGNMENTS FOR THE CAP v.l PROTOCOL FOLLOWS 

IMPORTS 

macros 
APPLICATION-SERVICE-ELEMENT 

FROM Remote-Operations-Notation-Extension ( joint-iso-ccitt remote-operations (4 ) notation- 
extension (2) } 

operation types 

ActivityTest, 

Connect, 

Continue, 

EventReportBCSM, 

InitialDP, 

ReleaseCall, 

RequestReportBCSMEvent 

FROM CAP-Operations ( ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) gsm-Network ( 1 ) 
modules (3) cap-operations (50 ) versionl(O)} 

CSl error types 

MissingCustomerRecord, 

MissingParameter, 

TaskRefused, 

UnexpectedComponent Sequence, 

UnexpectedDataValue, 

UnexpectedParameter 

FROM Core-INAP-CSl-Errors {ccitt(O) identif ied-organization (4 ) etsi(O) inDomain(l) in-network ( 1 ) 
modules (0) csl-errors (1) versionl(O)} 

— CAP error types 
SystemFailure 

FROM CAP-Errors {ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) gsm-Network ( 1 ) 
modules (3) cap-errors (51) versionl (0) } ; 

— the operations are grouped by the identified ASEs. 

— gsmSCF activation ASE 

initialDP InitialDP ::= localValue 

— Connect ASE (elementary gsmSSF function) 

connect Connect ;;= localValue 20 

— Call handling ASE (elementary gsmSSF function) 
releaseCall ReleaseCall ::= localValue 22 

— BCSM Event handling ASE 

requestReportBCSMEvent RequestReportBCSMEvent ::= localValue 23 
eventReportBCSM EventReportBCSM ::= localValue 24 

— gsmSSF call processing ASE 

continue Continue ::= localValue 31 
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— Activity Test ASE 

activityTest 

— ERROR codes 



ActivityTest 



localValue 55 



missingCustomerRecord MissingCustomerRecord 

missingParameter MissingParameter 

systemFailure SystemFailure 

taskRefused TaskRefused 

unexpectedComponent Sequence UnexpectedComponent Sequence 

unexpectedDataValue UnexpectedDataValue 

unexpectedParameter UnexpectedParameter 

— APPLICATION SERVICE ELEMENTS 



localValue 6 

localValue 7 

localValue 11 

localValue 12 

localValue 14 

localValue 15 

localValue 16 



gsmSCF-Activation-ASE 

— consumer is gsmSSF 
CONSUMER INVOKES { 
initialDP 



APPLICATION-SERVICE-ELEMENT 



Connect-ASE : := 

— supplier is gsmSCF 
SUPPLIER INVOKES { 

connect 
} 
Call-handling-ASE ::= 

— supplier is gsmSCF 
SUPPLIER INVOKES { 

releaseCall 
} 
BCSM-event-handling-ASE ::= 

— consumer is gsmSSF 
CONSUMER INVOKES { 

event Report BCSM 
} 

— supplier is gsmSCF 
SUPPLIER INVOKES { 

reque St Report BCSME vent 
} 
gsmSSF-call-processing-ASE ::= 

— supplier is gsmSCF 
SUPPLIER INVOKES { 

continue 



APPLICATION-SERVICE-ELEMENT 



APPLICATION-SERVICE-ELEMENT 



APPLICATION-SERVICE-ELEMENT 



APPLICATION-SERVICE-ELEMENT 



Activity-test-ASE 

— supplier is gsmSCF 
SUPPLIER INVOKES { 
activityTest 
} 
END 



APPLICATION-SERVICE-ELEMENT 



6.5 Application contexts 



APPLICATION-CONTEXT MACRO ::= 



BEGIN 

TYPE NOTATION 

VALUE NOTATION 

Symmetric 

Initiat or Consume rOf 

Re sponder Consume rOf 

ASEList 

ASE 

END 



Symmetric 1 InitiatorConsumerOf ResponderConsumerOf 1 empty 

value (VALUE OBJECT IDENTIFIER) 

"OPERATIONS OF" "{" ASEList "}" 

"INITIATOR CONSUMER OF" "{" ASEList "}" I empty 

"RESPONDER CONSUMER OF" "{" ASEList "}" I empty 

ASE I ASEList ", " ASE 

type — shall reference an APPLICATION-SERVICE-ELEMENT type. 



CAP-vl-gsmSSF-to-gsmSCF-AC APPLICATION-CONTEXT 
— dialogue initiated by gsmSSF with InitialDP 
INITIATOR CONSUMER OF { 

gsmSCF-activation-ASE, 

Connect-ASE 

Call-handling-ASE, 

BCSM-event-handling-ASE, 

gsmSSF- call-processing-ASE, 

Activity-test-ASE 

} 
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: := {ccitt(O) identif ied-organization (4) etsi(O) mobileDomain (0) gsm-Network (1) ac(0) 
cap-gsmssf-to-gsmscf (50) versionl(O)}; 



6.5 Classes 



CAP-Classes (ccitt(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) gsm-Network (1) modules (3) 
cap-classes (54) versionl (0) } 

— This module contains the class definitions for CAP v.l. 

DEFINITIONS : := 
BEGIN 

IMPORTS 

ROS-OBJECT-CLASS, CONTRACT, OPERATION-PACKAGE, Code, OPERATION, 
CONNECTION-PACKAGE 

FROM Remote-Ope rat ions -Information-Objects 

{ joint-iso-ccitt remote-operations (4) inf ormationOb jects (5 ) versionl (0)} 

EXTENSION ::= CLASS { 
SExtensionType, 

Scriticality CriticalityType DEFAULT ignore, 
Sid Code 
} 
WITH SYNTAX { 

EXTENSION-SYNTAX SExtensionType 
CRITICALITY Scriticality 
IDENTIFIED BY Sid 
} 
CriticalityType ::= ENUMERATED { 
ignore (0) , 
abort (1) 
} 

— Only value Global OBJECT IDENTIFIER is used for Sid 

— Only the value ignore (0) is used for &criticality . 

— Example of addition of an extension named 'Some Network Specific Indicator' of type 

— BOOLEAN, with criticality 'ignore' and to be identified with object ID 'ccitt(O) 

— identif ied-organization (4 ) organisation (x) gsm(x) capextension ' ; 

— Example of definition using the above information object class; 

— SomeNetworkSpecificIndicator EXTENSION ::= { 

— EXTENSION-SYNTAX BOOLEAN 

— CRITICALITY ignore 

— IDENTIFIED BY global : xxxxxx 

— } 

firstExtension EXTENSION ::= { 

EXTENSION-SYNTAX NULL 

CRITICALITY ignore 

IDENTIFIED BY global :{ xxxxxx } 

} 
SupportedExtensions EXTENSION ::= (firstExtension — full set of network operator extensions} 

END 



7 Application entity procedures 

The description of the application entity procedures for CAMEL can be found in GSM 03.78 [16]. 



8 Error procedures 



This subclause defines the generic error procedures for the CAP. The error procedure descriptions have been divided in 
two subclauses, subclause 8.1 listing the errors related to CAP operations and subclause 8.2 listing the errors related to 
error conditions in the different FEs which are not directly related to the CAP operations. 

The gsmSSF states which are referred to in this section are described in GSM 03.78 [16]. 
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8.1 Operation related error procedures 

The following subclauses define the generic error handling for the operation related errors. The errors are defined as 
operation errors in Clause 6. Errors which have a specific procedure for an operation are described in Clause 9 with the 
detailed procedure of the related operation. 

The TCAP services which are used for reporting operation errors are described in Clause 10. All errors which can be 
detected by the ASN.l decoder already may have been detected during the decoding of the TCAP message and indicated 
by the TC error indication "MistypedParameter". 

8.1.2-8.1.5 Spare 

8.1.6 MissingCustomerRecord 

8.1.6.1 General description 
8.1.6.1.1 Error description 

The SLP could not be found in the gsmSCF, because the required customer record does not exist. 

8.1 .6.2 Operations gsmSSF->gsmSCF 

InitialDP 

Procedures at invoking entity (gsmSSF) 

gsmSSF receives error "MissingCustomerRecord" 

precondition: gsmSSF state Waiting for Instructions 

postcondition: gsmSSF state Idle 

The GMSCA^MSC handles the call according to the Default Call Handling parameter of the valid CSI. 

8.1.6.3 Spare 

8.1.7 MlssingParameter 

8.1 .7.1 General description 
8.1.7.1.1 Error description 

There is an error in the received operation argument. The responding entity cannot start to process the requested 
operation because the argument is incorrect: an expected optional parameter which is essential for the application is not 
included in the operation argument. 

8.1 .7.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

RequestReportBCSMEvent 

Call Associated/Call Processing 
Connect 

Procedures at responding entity (gsmSSF) 

precondition: (1) gsmSSF appropriate state. 

(2) gsmSSF operation received, appropriate event occurred, 
postcondition: (1) gsmSSF transition to the same state. 

The gsmSSF detects the error in the received operation. The error parameter is returned to inform the gsmSCF of this 
situation. 
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8.1 .7.3 Operations gsmSSF->gsmSCF 

InitialDP 

Procedures at invoking entity (gsmSSF) 

gsmSSF receives error "MissingParameter" 

precondition: gsmSSF any state as result of the transfer of any of the above operations. 

postcondition: gsmSSF state Idle 

After receiving this error, the gsmSSF returns to the state Idle, the GMSC/VMSC handles the call according to the 

Default Call Handling parameter of the valid CSI. 

8.1.7.4-8.1.7.5 Spare 
8.1.8-8.1.9 Spare 
8.1.10 SystemFailure 

8.1.10.1 General description 

8.1.10.1.1 Error description 

This error is returned by a PE if it was not able to fulfil a specific task as requested by an operation, and recovery is not 
expected to be completed within the current call instance. 

8.1.10.1.2 Argument description 

PARAMETER 

UnavailableNet wo rkRe source 

UnavailableNetworkResource ::= ENUMERATED { 

unavailableResources (0) , 

componentFailure (1) , 

basicCallProcessingException (2) 
} 

8.1 .1 0.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

RequestReportBCSMEvent 

Call Associated/Call Processing 
Connect 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 0.3 Operations gsmSSF->gsmSCF 

InitialDP 

Refer to subclause 8.1.7 for the appropriate error procedures. 
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8.1.10.4 Spare 

8.1.11 TaskRefused 

8.1 .1 1 .1 General introduction 

8.1.11.1.1 Error description 

This error is returned by a PE if it was not able to fulfil a specific task as requested by an operation, and recovery is 
expected to be completed within the current call instance. 

8.1.11.1.2 Argument description 

PARAMETER ENUMERATED { 
generic (0) , 
unobtainable (1) , 
congestion (2) 
} 

8.1 .1 1 .2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

RequestReportBCSMEvent 

Call Associated/Call Processing 
Connect 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 1 .3 Operations gsmSSF->gsmSCF 

InitialDP 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1.11.4-8.1.11.5 Spare 

8.1.12 Spare 

8.1 .13 UnexpectedComponentSequence 

8.1 .1 3.1 General description 
8.1.13.1.1 Error description 

The responding entity cannot start the processing of the requested operation because a S ACF or MACF rule is violated, 
or the operation could not be processed in the current state of the receiving entity. 

8.1 .1 3.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

RequestReportBCSMEvent 

Call Associated/Call Processing 
Connect 
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In this case the gsmSSF detects the erroneous situation, sends the UnexpectedComponentSequence error and remains in 
the same state. 

8.1 .1 3.3 Operations gsmSSF->gsmSCF 

InitialDP 

In case the operation is sent by an "initiating" gsmSSF in the context of an existing relationship, the gsmSCF returns the 
error parameter. On receiving the error the gsmSSF moves to Idle. 

8.1.13.4-8.1.13.5 Spare 

8.1.14 UnexpectedDataValue 

8.1.14.1 General description 
8.1.14.1.1 Error description 

The responding entity cannot complete the processing of the requested operation because a parameter has an unexpected 
data value. 

NOTE: This error does not overlap with "ParameterOutOfRange". 

8.1 .1 4.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

RequestReportBCSMEvent 

Call Associated/Call Processing 
Connect 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 4.3 Operations gsmSSF->gsmSCF 

InitialDP 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1.14.4-8.1.14.5 Spare 

8.1.15 Unexpected Parameter 

8.1.15.1 General description 
8.1.15.1.1 Error description 

There is an error in the received operation argument. A valid but unexpected parameter was present in the operation 
argument. The presence of this parameter is not consistent with the presence of the other parameters. The responding 
entity cannot start to process the operation. 

8.1 .1 5.2 Operations gsmSCF->gsmSSF 

Call Associated/Non-call Processing 

RequestReportBCSMEvent 

Call Associated/Call Processing 
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Connect 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1 .1 5.3 Operations gsmSSF->gsmSCF 

InitialDP 

Refer to subclause 8.1.7 for the appropriate error procedures. 

8.1.15.4-8.1.15.5 Spare 
8.1.16 Spare 

8.2 Entity related error procedures 

The following subclauses define the error handling for the entity related errors. Since the error situations are not 
originated by the reception of an operation, the invoking entity is denoted here as the entity at which the error situation 
is detected. The responding entity is the entity which receives the error report. 

The TCAP services used for reporting errors are described in Clause 10. 

8.2.1 Expiration of TssF 

8.2.1 .1 General description 
8.2.1.1.1 Error description 

A timeout occurred in the gsmSSF on the response from the gsmSCF. 

8.2.1 .2 Procedures gsmSSF->gsmSCF 

Procedure at the invoking entity (gsmSSF) 

Timeout occurs in gsmSSF on T^gp 

precondition: gsmSSF state Waiting for instructions 

postcondition: gsmSSF state Idle 

The gsmSSF aborts the dialogue and moves to the Idle state, the GMSCA'^MSC handles the call according to the Default 

Call Handling parameter of the valid CSI. 

8.2.2 Spare 
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9 Detailed operation procedures 

The gsmSSF states which are referred to in this section are described in GSM 03.78 [16]. 

9.1 Spare 

9.2 ActivityTest procedure 

9.2.1 General description 

This operation is used to check for the continued existence of a relationship between the gsmSCF and gsmSSF. If the 
relationship is still in existence, then the gsmSSF will respond. If no reply is received, then the gsmSCF will assume that 
the gsmSSF has failed in some way and will take the appropriate action. 

9.2.1.1 Parameters 

None. 

9.2.2 Spare 

9.2.3 Responding entity (gsmSSF) 

9.2.3.1 Normal procedure 

gsmSSF precondition: 

1) A relationship exists between the gsmSCF and the gsmSSF. 

gsmSSF postconditions: 

1) The SSME FSM stays in, or moves to the state "Non-call Associated Treatment". 

2) If the dialogue ID is active and if there is a gsmSSF using the dialogue, the SSME sends a return result 
"ActivityTest" to the gsmSCF. If there are no other management activities, the SSME FSM returns to the state 
"Idle Management", or 

If the dialogue ID is not active, the TCAP in the gsmSSF will issue a P-Abort, the SSME will in that case never 
receive the ActivityTest operation and thus will not be able to reply. 

9.2.3.2 Error handling 

Not applicable. 

9.3-9.10 Spare 

9.1 1 Connect procedure 
9.11.1 General description 

This operation is used to request the gsmSSF to perform the call processing actions to route a call to a specific 
destination or to influence other call set-up information, e.g. the Generic Number. 
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9.11.1.1 Parameters 

destinationRoutingAddress: 

This parameter contains the called party number towards which the call is to be routed. 

callingPartysCategory: 

This parameter indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). 

originalCalledPartylD: 

This parameter carries the dialled digits if the call is forwarded by the gsmSCF. 

redirectingPartylD : 

This parameter indicates the directory number the call was redirected from. 

redirectionlnformation: 

This parameter contains forwarding related information, such as redirecting counter. 

genericNumbers : 

This parameter allows the gsmSCF to set the Generic Number parameter used in the network. It is used for 
transfer of Additional Calling Party Number. 

suppressionOfAnnouncement: 

This parameter indicates that announcements and tones which are played in the GMSC or the VMSC at non- 
successful call set-up attempts shall be suppressed. 

- oCSIAppHcable: 

This parameter indicates to the GMSC/gsmSSF that the Originating CAMEL Subscription Information, if 
present, shall be applied on the outgoing call leg created with the Connect operation. For the use of this 
parameter see GSM 03.78 [16]. 

9.11.2 Spare 

9. 11 .3 Responding entity (gsmSSF) 
9.1 1 .3.1 Normal procedure 

gsmSSF preconditions: 

1) Mobile originating or terminating call attempt has been initiated. 

2) Basic call processing has been suspended at a DP. 

3) The gsmSSF waits for instructions. 
gsmSSF postcondition: 

1) The gsmSSF performs the call processing actions to route the call to the specified destination. 
On receipt of this operation in the gsmSSF state "Waiting for Instructions", the gsmSSF performs the following actions: 
the gsmSSF cancels T^^p; 

if no EDPs have been armed the gsmSSF goes to state "Idle". Otherwise, the gsmSSF goes to state "Monitoring". 
No implicit activation or deactivation of DPs occurs. 
Statistic counter(s) are not affected. 
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9.11.3.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.12 Spare 

9.13 Continue procedure 

9.13.1 General description 

This operation is used to request the gsmSSF to proceed with call processing at the DP at which it previously suspended 
call processing to await gsmSCF instructions. The gsmSSF continues call processing without substituting new data from 
the gsmSCF. 

9.13.1.1 Parameters 

None. 

9.13.2 Spare 

9.13.3 Responding entity (gsmSSF) 

9.13.3.1 Normal procedure 

gsmSSF preconditions 

1) BCSM: Basic call processing has been suspended at any DP. 

2) gsmSSF is in the state "Waiting for Instructions". 

gsmSSF postconditions 

1) BCSM: Basic call processing continues. 

2) gsmSSF is in the state "Monitoring", because at least one EDP was armed, or 

gsmSSF is in the state "Idle", because no EDPs were armed. 

The gsmSSF is in state "Waiting for instructions".. The gsmSSF transitions to state "Idle" in case no EDPs are armed. 
The gsmSSF transits to state "Monitoring" if at least one EDP is armed. Basic call processing is resumed. 

9.13.3.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

9.14-9.16 Spare 

9.17 EventReportBCSM procedure 
9.17.1 General description 

This operation is used to notify the gsmSCF of a call related event previously requested by the gsmSCF in an 
RequestReportBCSMEvent operation. The monitoring of more than one event could be requested with a 
RequestReportBCSMEvent operation, but each of these requested events is reported in a separate EventReportBCSM 
operation. 
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9.17.1.1 Parameters 

- eventTypeBCSM: 

This parameter specifies the type of event that is reported. 

eventSpecificInformationBCSM: 

This parameter indicates the call related information specific to the event. 

For O- or T- Answer it will be empty. 

For O- or T-Disconnect it will contain the "releaseCause", if available. 

- leglD: 

This parameter indicates the party in the call for which the event is reported. gsmSSF will use the option 
"receivings idelD" only. 

receivingSidelD: 

The following values for "leglD" are assumed: 

"leglD" = 1 indicates the party that was present at the moment of the InitialDP. 

"leglD" = 2 indicates the party that was created with a Connect operation (Continue operation). 

If not included, the following defaults are assumed: 

"leglD" = 2 for the events O- Answer and T-Answer. 

The "leglD" parameter shall always be included for the events O-Disconnect and T-Disconnect. 

miscCalllnfo: 

This parameter indicates DP related information. 

messageType: 

This parameter indicates whether the message is a request, i.e. resulting from a RequestReportBCSMEvent 
with "monitorMode" = "interrupted", or a notification, i.e. resulting from a RequestReportBCSMEvent with 
"monitorMode" = "notifyAndContinue". 

9.1 7.2 Invoking entity (gsmSSF) 
9.17.2.1 Normal procedure 

gsmSSF preconditions: 

1) The gsmSSF shall be in the state "Monitoring"; or 

the gsmSSF may be in state "Waiting for Instructions" if the Disconnect DP is armed and encountered. 

2) The BCSM proceeds to an EDP that is armed. 
gsmSSF postconditions: 

1) The gsmSSF stays in the state "Monitoring" if the message type was notification and there are still EDPs armed. 

2) The gsmSSF moves to the state "Idle" if the message type was notification and there are no more EDPs armed. 

3) The gsmSSF moves to the state "Waiting for Instructions" if the message type was request. Call processing is 
interrupted. 

If a EDP-R is met that causes the release of the related leg all EDPs related to that leg are disarmed and the event is 
reported via EventReportBCSM. 
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9.17.2.2 Error handling 

In case the message type is request, on expiration of T^gp before receiving any operation, the gsmSSF aborts the 
interaction with the gsmSCF and instructs the GMSC/MSC to handle the call according to the Default Call Handling 
parameter of the valid CSI. 

Operation related error handling is not applicable, due to class 4 operation. 

9.17.3 Spare 

9.18 Spare 

9.19 InitialDP procedure 
9.19.1 General description 

This operation is sent by the gsmSSF after detection of a TDP-R in the BCSM, to request the gsmSCF for instructions to 
complete the call. 

9.19.1.1 Parameters 

serviceKey: 

This parameter identifies for the gsmSCF unambiguously the requested IN service. It is used to address the 
correct application/SLP within the gsmSCF (not for gsmSCF addressing). 

calledPartyNumber: 

This parameter contains the number used to identify the called party in the forward direction, e.g. the Called 
party number of ISUP (see ETS 300 356-1 [4]). This parameter shall be sent only in the Mobile Forwarding and 
Mobile Terminating cases. 

callingPartyNumber: 

This parameter carries the calling party number to identify the calling party or the origin of the call. The 
encoding of the parameter is defined in ETS 300 356-1 [4]. 

callingPartysCategory: 

Indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). 

originalCalledPartylD: 

This parameter carries the dialled digits if the call has met call forwarding on the route to the gsmSSF. 

locationNumber: 

This parameter is used to convey the geographical area address for mobility services. It is used when 
"callingPartyNumber" does not contain any information about the geographical location of the calling party (e.g., 
origin dependent routing when the calling party is a mobile subscriber). 

bearerCapability: 

This parameter indicates the type of the bearer capability connection to the user: 

bearerCap: 

This parameter contains the value of the ISUP User Service Information parameter. 
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The parameter "bearerCapability" shall only be included in the InitialDP operation in case the ISUP User Service 
Information parameter is available at the gsmSSF. 

If User Service Information and User Service Information Prime are available at the gsmSSF the "bearerCap" 
shall contain the value of the User Service Information Prime parameter. 

- eventTypeBCSM: 

This parameter indicates the armed BCSM DP event, resulting in the InitialDP operation. 

- redirectingPartylD: 

This parameter indicates the directory number the call was redirected from. 

redirectionlnformation: 

It contains forwarding related information, such as redirecting counter. 

additionalCallingPartyNumber: 

The calling party number provided by the access signalling system of the calling user. 

highlayerCompatibility: 

This parameter indicates the type of the high layer compatibility, which will be used to determine the ISDN- 
teleservice of a connected ISDN terminal. For encoding, DSS 1 (see ETS 300 403-1 [5]) is used. 

- iMSI: 

IMSI of the mobile subscriber for which the CAMEL service is invoked. For encoding see GSM 09.02 [15]. 

- subscriberState: 

The state of the mobile subscriber for which the CAMEL service is invoked. The possible states are busy, idle 
and not reachable. For encoding see GSM 09.02 [15]. 

locationlnformation: 

This parameter indicates the whereabouts of the MS, and the age of the information defining the whereabouts. 
For encoding see GSM 09.02 [15]. 

- ext-BasicServiceCode: 

Indicates the Basic Service Code. For encoding see GSM 09.02 [15]. 

callReferenceNumber: 

This parameter gives the call reference number assigned to the call by the GMSC/MSC. For encoding see GSM 
09.02 [15]. 

- mscAddress: 

This parameter gives the mscid assigned to the GMSC/MSC. For encoding see GSM 09.02 [15]. 

- calledPartyBCDNumber: 

This parameter contains the number used to identify the called party in the forward direction. It may also include 
service selection information, including * and # digits. This parameter shall be sent only in the Mobile 
Originating case. 



9.1 9.2 Invoking entity (gsmSSF) 
9.19.2.1 Normal procedure 

gsmSSF preconditions: 
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1) Call origination attempt has been initiated. 

2) An event has been detected at a DP. 
gsmSSF postcondition: 

1) A control relationship has been established and the gsmSSF waits for instructions from the gsmSCF. 

The address of the gsmSCF the InitialDP operation shall be sent to is fetched from the valid CSI. The gsmSSF provides 
all available parameters. 

A control relationship is established to the gsmSCF. The gsmSSF application timer T^gp is set when the gsmSSF sends 
InitialDP for requesting instructions from the gsmSCF. It is used to prevent from excessive call suspension time. 

9.19.2.2 Error handling 

If the destination gsmSCF is not accessible then the gsmSSF instructs the GMSC/MSC to handle the call according to 
the Default Call Handling parameter of the valid CSI. 

On expiration of Tg§p before receiving any operation, the gsmSSF aborts the interaction with the gsmSCF and instructs 
the GMSC/VMSC to handle the call according to the Default Call Handling parameter of the valid CSI. 

If the calling party abandons after the sending of InitialDP, then the gsmSSF aborts the control relationship after the first 
answer message from the gsmSCF has been received. 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 

9.19.3 Spare 
9.20-9.22 Spare 

9.23 ReleaseCall procedure 

9.23.1 General description 

This operation is used to tear down by the gsmSCF an existing call at any phase of the call for all parties involved in the 
call. The operation can only be sent within a control relationship and is not allowed in a monitor relationship. 

9.23.1.1 Parameters 

Cause 

A number giving an indication to the gsmSSF about the reason of releasing this specific call. This may be used 
by gsmSSF for generating specific tones to the different parties in the call or to fill in the "cause" in the release 

message. 

9.23.2 Spare 

9.23.3 Responding entity (gsmSSF) 
9.23.3.1 Normal procedure 

gsmSSF preconditions: 

1) State "Waiting for Instructions"; or 
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State "Monitoring". 
gsmSSF postcondition: 
1) "Idle". Possible armed EDPs are ignored. All connections and resources related to the call are released. 

9.23.3.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

9.24 Spare 

9.25 RequestReportBCSM Event procedure 
9.25.1 General description 

This operation is used to request the gsmSSF to monitor for a call-related event, then send a notification back to the 
gsmSCF when the event is detected. 

9.25.1.1 Parameters 

bcsmEvents: 

This parameter specifies the event or events of which a report is requested. 

- eventTypeBCSM: 

This parameter specifies the type of event of which a report is requested. Values collectedlnfo and 
termAttemptAuthorized are not valid for the RequestReportBCSMEvent operation. 

monitorMode: 

This parameter indicates how the event should be reported. When the "monitorMode" is "interrupted", the 
event shall be reported as a request; if the "monitorMode" is "notify AndContinue", the event shall be reported 
as a notification. 

- leglD: 

This parameter indicates the party in the call for which the event shall be reported. gsmSCF will use the 
option "sendingSidelD" only. 

sendingSidelD: 

The following values for "leglD" are assumed: 

"leglD" = 1 indicates the party that was present at the moment of the InitialDP. 

"leglD" = 2 indicates the party that was created with a "Connect" operation (Continue operation). 

If not included, the following defaults are assumed: 

"leglD" = 2 for the events O- Answer and T-Answer. 

The "leglD" parameter shall always be included for the events O-Disconnect and T-Disconnect. 
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9.25.2 Spare 

9.25.3 Responding entity (gsmSSF) 

9.25.3.1 Normal procedure 

gsmSSF precondition: 

1) The gsmSSF is in the state "Waiting for Instructions". 

gsmSSF postconditions: 

1) The requested EDPs have been armed as indicated. 

2) Previously requested events are monitored, until the end of the call, until the EDPs are detected or until the 
corresponding leg is released. 

3) The gsmSSF remains in the same state. 

9.25.3.2 Error handling 

Generic error handling for the operation related errors is described in Clause 8 and the TCAP services which are used 
for reporting operation errors are described in Clause 10. 



9.26-9.29 Spare 



1 Services assumed from TCAP 
10.1 Normal procedures 

This subclause describes the procedures and TCAP primitives that shall be used for transmitting messages between 
gsmSSF and gsmSCF under normal operation. 

The CAP, as TC-user, uses only the structured dialogue facility provided by TCAP. The following situations can occur 
when a message is sent between two physical entities: 

a dialogue shall be established: the TC-user issues a TC-BEGIN request primitive; 

a dialogue shall be maintained: the TC-user issues a TC-CONTINUE request primitive; 

a dialogue shall no longer be maintained: the TC-user issues a TC-END request primitive with either basic end or 
with pre-arranged end depending on the following conditions: 

basic end: 

operations leading to a termination of the control relationship can be transmitted by the gsmSCF with a 
TC-END request primitive (basic) in case the gsmSCF is not interested in the reception of any ERROR or 
REJECT components for these sent operations; 

once the gsmSCF dialogue resources have been released any ERROR or REJECT components received 
for these sent operations will be discarded by TC as described in ETS 300 287 [3] (ITU-T 
Recommendation Q.774); 

if the gsmSCF entity has received an operation leading to the termination of the control relationship, a 
TC-END request primitive (basic) with zero components can be sent from the gsmSCF; 

- pre-arranged end: 
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in case of an entity being interested in possible ERROR or REJECT messages in response to sent operations 
leading to a termination of the control relationship, the dialogue is ended with a TC-END request primitive 
(pre-arranged end) after the last associated operation timer expires. The receiving entity shall end the 
dialogue with a TC-END request primitive (basic or pre-arranged end) after successful processing of these 
operations (i.e. the control relationship is terminated); 

10.1.1 gsmSSF-to-gsmSCF messages 

10.1.1.1 gsmSSF related messages 

A dialogue shall be established when the gsmSSF has finalised triggerprocessing and moves to the state Waiting for 
Instructions. The relevant CAP operation, which can only be the InitialDP operation, shall be transmitted in the same 
message. 

For all other operations sent from the gsmSSF, the dialogue shall be maintained. 

The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSSF. When the 
gsmSSF makes a state transition to the state Idle, the dialogue is locally ended by means of a TC-END request primitive 
with prearranged end. 

When the gsmSSF has sent the last EventReportBCSM the dialogue may be ended from the gsmSCF by a TC-END 
request primitive with basic end. 

10.1.1.2 Spare 

10.1.1.3 SSME FSM related messages 

The following procedures shall be followed: 

the dialogue shall be maintained when the ActivityTest return result is sent; 

10.1.2 gsmSCF-to-gsmSSF messages 

1 0.1 .2.1 SCSM FSM related messages 

For subsequent operations sent from the SCSM FSM, the dialogue shall be maintained, i.e. all other operations are sent 
after a dialogue was established from the gsmSSF (the gsmSCF has previously received a TC-BEGIN indication 
primitive with an InitialDP operation). 

The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSCF. When the 
gsmSCF does not expect any messages other than possibly REJECT or ERROR messages for the operations sent and 
when the last associated operation timer expires, the dialogue is locally ended by means of a TC-END request primitive 
with prearranged end. 

Alternatively, the sending of operations, leading to the termination of the control relationship, by means of a TC-END 
request primitive (basic end) is possible. 

1 0.1 .2.2 SCME FSM related messages 

The operations sent from the SCME FSM shall be issued according to the following procedures: 
the dialogue shall be maintained when the ActivityTest operation is sent; 
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10.1.3 Spare 

10.2 Abnormal procedures 

This subclause describes the procedures and TCAP primitives that shall be used for reporting abnormal situations 
between gsmSSF and gsmSCF. The error cases are defined in Clause 8. 

The following primitives shall be used to report abnormal situations: 

operation errors, as defined in the CAP, are reported with TC-U-ERROR request primitive; 

rejection of a TCAP component by the TC-user shall be reported with TC-U-REJECT request primitive; 

a dialogue shall be aborted by the TC-user with a TC-U-ABORT request primitive. 

For abnormal situations detected by TCAP the same rules shall apply for transmission of TC-R-REJECT indication as 
for transmission of TC-U-REJECT request and for transmission of TC-P- ABORT indication as for transmission of 
TC-U-ABORT request primitive. 

In error situations prearranged end shall not be used. In case any AE encounters an error situation the peer entity shall be 
explicitly notified of the error, if possible. If from any entity's point of view the error encountered requires the 
relationship to be ended, it shall close the dialogue via a TC-END request primitive with basic end or via a 
TC-U-ABORT request primitive, depending on whether any pending ERROR or REJECT component is to be sent or 
not. 

In case an entity receives a TC-END indication primitive and after all components have been considered, the gsmSSF is 
not in a state to terminate the control relationship, an appropriate internal error should be provided. 

In cases when a dialogue needs to be closed by the initiating entity before its establishment has been completed (before 
the first TC indication primitive to the TC-BEGIN request primitive has been received from the responding entity), the 
TC-user shall issue a TC-END request primitive with prearranged end or a TC-U-ABORT request primitive. The result 
of these primitives will be only local, any subsequent TC indication received for this dialogue will be handled according 
to the abnormal procedures as specified in ETS 300 287 [3] (ITU-T Recommendation Q.774). 



10.2.1 gsmSCF-to-gsmSSF messages 



Considering that gsmSSF does not have the logic to recover from error cases detected on the gsmSCF-gsmSSF interface, 
the following shall apply: 

operation errors and rejection of TCAP components shall be transmitted to the gsmSSF with a TC-END request 
primitive, basic end. 

If, in violation of the above procedure, an ERROR or REJECT component is received with a TC-CONTINUE indication 
primitive, the gsmSSF shall abort the dialogue with a TC-U-ABORT request primitive. 



10.2.2 gsmSSF-to-gsmSCF messages 



Operation errors and rejection of TCAP components shall be transmitted to the gsmSCF according to the following 
rules: 

the dialogue shall be maintained when the preceding message, which contained the erroneous component, 
indicated that the dialogue shall be maintained. I.e. the error or reject shall be transmitted with a TC-CONTINUE 
request primitive if the erroneous component was received with a TC-CONTINUE indication primitive; 

on receipt of an ERROR or REJECT component the gsmSCF decides on further processing. It may either 
continue, explicitly end or abort the dialogue; 

If the error processing in the gsmSSF leads to the case where the gsmSSF is not able to process further gsmSCF 
operations while the dialogue is to be maintained, the gsmSSF aborts the dialogue with a TC-U-ABORT request 
primitive. 
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The gsmSSF aborts a dialogue with a TC-U-ABORT request primitive in case call release is initiated by any other entity 
then the gsmSCF and the gsmSSF has no armed EDP to notify the gsmSCF of the call release. 



10.3 Dialogue establishment 



The establishment of an CAP dialogue involves two application processes as described in subclause 4.3, one that is the 
dialogue-initiator and one that is the dialogue-responder. 

AC negotiation may not be supported in all physical entities and/or all networks. 

This procedure is driven by the following signals: 

a TC-BEGIN request primitive from the dialogue-initiator; 

a TC-BEGIN indication primitive occurring at the responding side; 

the first TC-CONTINUE indication primitive occurring at the initiating side or under specific conditions: 

a TC-END indication primitive occurring at the initiating side; 

a TC-U-ABORT indication primitive occurring at the initiating side; 

a TC-P-ABORT indication primitive occurring at the initiating side. 

1 0.3.1 Sending of a TC-BEGIN request primitive 

Before issuing a TC-BEGIN request primitive, S ACE shall store the AC-name and if present the user-information 
parameter. 

SACF shall request the invocation of the associated operations using the TC-INVOKE service. See subclause 10.8 for a 
description of the invocation procedure. 

After processing of the last invocation request, SACF shall issue a TC-BEGIN request primitive. 

The requesting side SACF then waits for a TC indication primitive and will not issue any other requests, except a 
TC-U-ABORT request or a TC-END request with the release method parameter set to "pre-arranged release". 

1 0.3.2 Receipt of a TC-BEGIN indication 

On receipt of a TC-BEGIN indication primitive, SACF shall: 

analyze the application-context-name included in the primitive and if it is supported, process any other indication 
primitives received from TC as described in subclause 10.8. 

Once all the received primitives have been processed, SACF does not accept any primitive from TC, except a 
TC-P-ABORT indication. 

If the application-context-name included in the primitive is not supported, issue a TC-U-ABORT request primitive. If an 
alternative application-context can be offered its name is included in the TC-U-ABORT request primitive. 

1 0.3.3 Receipt of the first TC-CONTINUE indication 

On receipt of the first TC-CONTINUE indication primitive for a dialogue, SACF shall check the value of the 
application-context-name parameter. If this value matches the one used in the TC-BEGIN request primitive, SACF shall 
process the following TC component handling indication primitives as described in subclause 10.8, otherwise it shall 
issue a TC-U-ABORT request primitive. 



1 0.3.4 Receipt of a TC-END indication 



On receipt of a TC-END indication primitive in the dialogue initiated state, SACF shall check the value of the 
application-context-name parameter. If this value matches the one used in the TC-BEGIN request primitive then the 
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SACF shall process the following TC component handling indication primitives as described in subclause 10.8, 
otherwise it shall not be processed. 

1 0.3.5 Receipt of a TC-U-ABORT indication 

Receipt of a TC-U-ABORT indication primitive is described as part of user abort procedure (see subclause 10.6.2). 

If the abort reason is application-context-name not supported, the responding side may propose an alternative 
application-context-name in the TC-U-ABORT indication. If an alternative application context is proposed the receiving 
entity shall check this name and if it can be supported a new dialogue may be established. 

1 0.3.6 Receipt of a TC-P-ABORT indication 

Receipt of a TC-P-ABORT indication primitive is described as part of provider abort procedure (see subclause 10.7.1). 

10.4 Dialogue continuation 

Once established the dialogue is said to be in a continuation phase. 

Both application processes can request the transfer of CAP APDUs until one of them requests the termination of the 
dialogue. 

10.4.1 Sending entity 

SACF shall process any component handling request primitives as described in subclause 10.8. 

After processing the last component handling request primitive, SACF shall issue a TC -CONTINUE request primitive. 

10.4.2 Receiving entity 

On receipt of a TC-CONTINUE indication primitive SACF shall accept zero, one or several TC component handling 
indication primitives and process them as described in subclause 10.8. 



10.5 Dialogue termination 



Both the dialogue-initiator and the dialogue-responder have the ability to request the termination of a dialogue when no 
dialogue is to be established or when a dialogue is no longer to be maintained according to the rules as stated in 
subclauses 10.1 and 10.2. 

The dialogue termination procedure is driven by the following events: 

a TC-END request primitive; 

a TC-END indication primitive. 



1 0.5.1 Sending of TC-END request 



When the dialogue shall no longer be maintained, SACF shall process any component handling request primitives as 
described in subclause 10.8. 

After processing the last component handling request primitive (if any), SACF shall issue a TC-END request primitive 
with the release method parameter set to "basic end" or "pre-arranged release", according to the rules as stated in 
subclauses 10.1 and 10.2. 

When no dialogue is to be established, refer to subclauses 10.3.1 and 10.3.2. 
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1 0.5.2 Receipt of a TC-END indication 

On receipt of a TC-END indication primitive, the SACF shall accept any component handling indication primitives and 
process them as described in subclause 10.8. 

After processing the last component handling primitive all dialogue related resources are released. 

10.6 User Abort 

Both the dialogue-initiator and the dialogue-responder have the ability to abort a dialogue at any time. 
The user abort procedure is driven by one of the following events: 

a TC-U-ABORT request primitive; 

a TC-U-ABORT indication primitive. 

1 0.6.1 Sending of TC-U-ABORT request 

After issuing a TC-U-ABORT request primitive, all dialogue related resources are released. 

1 0.6.2 Receipt of a TC-U-ABORT indication 

On receipt of a TC-U-ABORT indication all dialogue related resources are released. 

10.7 Provider Abort 

TC has the ability to abort a dialogue at both the dialogue-initiator side and the dialogue-responder side. 
The provider abort procedure is driven by the following event: 
a TC-P- ABORT indication primitive. 

10.7.1 Receipt of a TC-P-ABORT indication 

On receipt of a TC-P-ABORT indication, all dialogue related resources are released. 

1 0.8 Procedures for CAP operations 

This subclause describes the procedures for CAP operations. 



10.8.1 Operation invocation 



SACF shall build an operation argument from the parameters received and request the invocation of the associated 
operation using the TC-INVOKE procedure. 

1 0.8.2 Operation invocation receipt 

On receipt of a TC-INVOKE indication primitive, SACF shall: 

if the invoke ID is already in use by an active operation, request the transfer of a reject component using the 
TC-U-REJECT request primitive with the appropriate problem code (duplicated invokelD); 

if the operation code does not correspond to an operation supported by the application-context, request the 
transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate problem code 
(unrecognized operation); 
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if the type of the argument is not the one defined for the operation, request the transfer of a reject component 
using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter); 

if the operation cannot be invoked because the dialogue is about to be released, requests the transfer of a reject 
component using the TC-U-REJECT request primitive with the problem code (Initiating Release); 

if sufficient CAP related resources are not available to perform the requested operation, request the transfer of a 
reject component using the TC-U-REJECT request primitive with the problem code (Resource Limitation); 

otherwise, accept the TC-INVOKE indication primitive. If the operation is to be user confirmed, S ACF waits for 
the corresponding response. 

10.8.3 Operation response 

For user confirmed operations, SACF shall: 

if no error indication is included in the response to a class 1 or 3 operation, construct a result information element 
from the parameters received and request its transfer using the TC-RESULT-L service; 

if an error indication is included in the response to a class 1 or 2 operation, construct an error parameter from the 
parameters received and request its transfer using the TC-U-ERROR request primitive. 

1 0.8.4 Receipt of a response 

1 0.8.4.1 Receipt of TC-RESULT-NL indication 

On receipt of a TC-RESULT-NL indication, SACF shall: 

request the transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate 
problem code (mistyped parameter). 

1 0.8.4.2 Receipt of TC-RESULT-L indication 

On receipt of a TC-RESULT-L indication, SACF shall: 

if the type of the result parameter is not the one defined for the result of this operation, request the transfer of a 
reject component using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped 
parameter); 

otherwise, accept the TC-RESULT-L indication primitive. 

1 0.8.4.3 Receipt of TC-U-ERROR indication 

On receipt of a TC-U-ERROR indication, SACF shall: 

if the error code is not defined for the SACF or is not one associated with the operation referred to by the invoke 
identifier, request the transfer of a reject component using the TC-U-REJECT request primitive, with the 
appropriate problem code (unrecognized error or unexpected error); 

if the type of the error parameter is not the one defined for this error, request the transfer of a reject component 
using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter); 

otherwise, accept the TC-U-ERROR indication primitive. 

1 0.8.4.4 Receipt of TC-U-REJECT indication 

On receipt of a TC-U-REJECT indication primitive which affects a pending operation, SACF shall accept the 
TC-U-REJECT indication primitive. 
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1 0.8.4.5 Receipt of a TC-L-REJECT indication 

This event occurs when the local TC detects a protocol error in an incoming component which affects an operation. 

On receipt of a TC-L-REJECT indicating "return result problem, return result unexpected", SACF shall inform the 
application process. 

On receipt of a TC-L-REJECT indicating "return error problem, return error unexpected", SACF shall inform the 
application process. 

When the problem code indicates a general problem, it is considered that the event cannot be related to an active 
operation even if the invoke ID is provided by TC. This is because it is unclear whether the invoke ID refers to a local or 
remote invocation. The behaviour of SACF in such a case is described in subclause 10.8.5.3. 

1 0.8.4.6 Receipt of a TC-L-CANCEL indication 

On receipt of a TC-L-CANCEL indication, the SACF shall: 

if the associated operation is a class 1 operation, inform the application process; 

if the associated operation is a class 2 operation and no linked operations are defined for this operation, ignore 
the primitive; 

if the associated operation is a class 2 operation and has linked operations but none of them has been invoked, 
inform the application process; 

if the associated operation is a class 2 operation and a linked operation invocation has already been received in 
response to this operation, ignore the primitive; 

if the associated operation is a class 3 operation, inform the application process; 

if the associated operation is a class 4 operation, ignore the primitive. 

10.8.5 Other events 

This subclause describes the behaviour of SACF on receipt of a component handling indication primitive which cannot 
be related to any operation or which does not affect a pending one. 

1 0.8.5.1 Receipt of a TC-U-REJECT 

On receipt of a TC-U-REJECT indication primitive which does not affect an active operation (i.e. indicating a return 
result or return error problem), it is up to the application process to abort, continue or terminate the dialogue, if not 
already terminated by the sending application process according to the rules as stated in subclause 10.2. This is also 
applicable for invoke problems related to a class 4 linked operation. 

1 0.8.5.2 Receipt of a TC-R-REJECT indication 

On receipt of a TC-R-REJECT indication (i.e. when a protocol error has been detected by the peer TC entity) which 
does not affect an active operation, it is up to the application process to abort, continue or terminate the dialogue, if not 
already terminated by the sending application process according to the rules as stated in subclause 10.2. 

1 0.8.5.3 Receipt of a TC-L-REJECT indication 

On receipt of a TC-L-REJECT indication primitive (i.e. when a protocol error has been detected by the local TC entity) 
which cannot be related to an active operation, it is up to the application process to continue, or to terminate the 
dialogue and implicitly trigger the transmission of the reject component or to abort the dialogue. 



GSM 09.78 version 5.3.0 46 TS 1 01 046 V5.3.0 (1 998-01 ) 

1 0.8.5.4 Receipt of a TC-NOTICE indication 

This informs the S ACF that a message cannot be dehvered by the Network Layer, this can only occur if the Return 
Option has been set (see subclause 10.9.1.8). It is for the application process to decide whether to terminate the dialogue 
or retry. 

1 0.9 Mapping on to TC services 

10.9.1 Dialogue control 

The TC-UNI service is not used by CAP. 

10.9.1.1 Destination address 

This parameter is set by the dialogue initiating application process, and may optionally be modified by the responding 
dialogue in the first backward TC-CONTINUE. 

10.9.1.2 Originating address 

This parameter is set by the dialogue initiating application process. 

10.9.1.3 Dialogue ID 

The value of this parameter is associated with the CAP invocation in an implementation dependent manner. 

1 0.9.1 .4 Application-context-name 

The application-context-name parameter is set by SACF as defined in subclause 6.4. 

10.9.1.5 User information 

This parameter may be used by both initiating and responding application processes. 

10.9.1.6 Component present 

This parameter is used by SACF as described in ETS 300 287 [3] (ITU-T Recommendation Q.771). 

10.9.1.7 Termination 

The value of the release method parameter of the TC-END request primitive is set by SACF according to the rules as 
stated in subclauses 10.1 and 10.2. 

10.9.1.8 Quality of service 

The quality of service of TC request primitives is set by the SACF to the following value: 
sequencing requested if required by the application (see section 4.4.2); 
return option as required by the application (see section 4.4.2). 

10.9.2 Operation procedures 
10.9.2.1 invoke ID 

This parameter is set by the sending application process. 
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10.9.2.2 Linked ID 

This parameter is set by the sending application process. 

10.9.2.3 Dialogue ID 

The value of this parameter is associated with the CAP invocation in an implementation dependent manner. 

10.9.2.4 Class 

The value of this parameter is set by S ACF according to the type of the operation to be invoked according to 
subclause 6. 1 . 

10.9.2.5 Operation 

The operation code of a TC -INVOKE request primitive is set by the sending application process as defined in 
subclause 6.4. 

S ACF shall set the operation code of the TC-RESULT-L primitive (if required) to the same value as the one received at 
invocation time. 

10.9.2.6 Error 

The error parameter of the TC-U-ERROR request primitive is set by the sending application process as defined in 
subclause 6.4. 

10.9.2.7 Parameters 

The argument parameter of TC -INVOKE primitives is set by the sending application process as defined in 
subclauses 6.1 and 6.3. 

The result parameter of TC-RESULT-L primitives is set by the sending application process as defined in subclauses 6. 1 
and 6.3. 

The parameter of TC-U-ERROR primitives are set by the sending application process as defined in subclauses 6.2 and 
6.3. 

10.9.2.8 Timeout 

The value of this parameter is set by S ACF according to the type of operation invoked. 

10.9.2.9 Last component 

This parameter is used by SACF as described in ETS 300 287 [3] (ITU-T Recommendation Q.771). 

10.9.2.10 Problem code 

This parameter is used by SACF as described in subclause 10.8. 
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Annex A (normative): 

Mapping between CAP and ISUP 



This annex defines the mapping between the CAP parameters and the call parameters sent/received in the ISUP. The 
functional handling of these parameters is defined in GSM 03.78 [16]. 



A.1 InitialDP operation 



Table A.I 



ISUP message 
JAM (Note 1) 


CAP operation 
InitialDP 


Called party number 


calledPartyNumber 


Calling party number 


callingPartyNumber 


CalHng party's category 


callingPartysCategory 


Location number 


locationNumber 


Original called number 


originalCalledPartylD 


User teleservice information (1st priority) 

High layer compatibility IE contained in access transport 
(2nd priority) (Note 2) 


highLayerCompatibility 


Generic number 'additional calling party number' 


additionalCallingPartyNumber 


User service information prime (1st priority) 
User service information (2nd priority) 


bearerCapabiUty 


Redirecting number 


redirectingPartylD 


Redirection information 


redirectionlnformation 



NOTE 1: Optional parameters may be absent, i.e. they are only mapped, if these parameters are available at the DP. 

NOTE 2: If two high layer compatibility information elements are contained in the access transport parameter, then 
the second information element, carrying the preferred HLC, is mapped to the CAP 
highLayerCompatibility parameter. 



A.2 Connect operation 



On receipt of a Connect operation from the gsmSCF the called party number used for routing is derived from the 
destinationRoutingAddress (see Table A.2). If the triggering of the CAMEL service was made for a mobile terminating 
or forwarded call, an ACM message shall be sent to the preceding exchange. The encoding of the backward call 
indicators in the ACM is specified in GSM 09.12 [24]. 

Table A.2 illustrates the mapping of parameters received in the Connect operation to parameters sent in the lAM 
message to the succeeding exchange. Parameters which were received in the lAM and are not replaced by parameters of 
the Connect operation are treated according to the normal procedures. 

On sending of the lAM the awaiting address complete timer is started. If the timer expires the call is released in both 
directions and an appropriate indication is returned to the calling subscriber. 
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Table A.2 



CAP operation 
Connect (Note 1) 


ISUP message 
lAM 


destinationRoutingAddress 


Called party number 


originalCalledPartylD 


Original called number 


callingPartysCategory 


Calling party's category 


redirectingPartylD 


Redirecting number 


redirectionlnformation 


Redirection information 


genericNumbers 


Generic number (Note 2) 



NOTE 1: Optional parameters may be absent, i.e. they are only mapped, if received. 

NOTE 2: The set of generic numbers received in the genericNumbers parameter is mapped to the appropriate 
number of Generic Number parameters in the ISUP lAM. This shall be performed irrespective of the 
value of the screening indicator in the ISUP calling party number. 



A.3 ReleaseCall operation 



Upon receipt of the ReleaseCall operation, the GMSC/gsmSSF (VMSC/gsmSSF) sends REL messages in both 
directions. The cause indicators parameter contains the releaseCallArg parameter of the ReleaseCall operation. 
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Annex B (informative): 
Change History 
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